◀ Prev • Parts • Full • Next ▶

Forward secrecy means that if the encryption of a single exchange is broken, no other exchange is compromised. This means if not all traffic is sensitive, it’s possible that an attacker could spend days, months, or even years of machine time to decrypt a lunch order, and all other messages would remain secure.

This is not legal advice, as even if a contributor were to be a lawyer, they are not your lawyer.

So long as encrypted communication is legal in your jurisdiction, it’s almost certain Reticulum itself is legal. Reticulum is always encrypted, so any law preventing encryption will affect its legality.

In many jurisdictions, transmitting encrypted data over the radio is restricted, especially in amateur radio bands. Any license will clearly state what can and cannot be done on the band, be it a public or private band.

Unlicensed bands vary greatly between band and jurisdiction. This can cover not just frequency, but duty cycle and radiated power (both in raw dBm and in directed power, taking into account a directional antenna). For example, Digikey provides some basic guidance regarding LoRa products, but even this requires substantial investigation to ensure compliance. Many of the supported RNode boards from LilyGO are both FCC certified and are within frequency and power limits for most regions.

If your jurisdiction has laws regarding "service providers" for E2EE messengers, the distribution network functionality of NomadNet can be disabled, turning a node into a router without any storage of user data (which is encrypted and unavailable to the server in any case). Similarly, a node doesn’t need to have a TCP server, further isolating the node from such restrictions.

Reticulum is as legal as any other system providing the same functionality, so laws regarding encryption over the Internet, radio, telephone, wire, broadcast, etc. all apply. This is a tremendously complicated field, and if there’s any question, a specialist attorney would need to be told the specific application in question.

You may have seen that the docs say, “Every node can become a transport node, simply by enabling it in its configuration, but there is no need for every node on the network to be a transport node. Letting every node be a transport node will in most cases degrade the performance and reliability of the network,” and you might wonder why that is the case. Mark Qvist explains:cite-ref-2[2]

Routing traffic is not free, it requires some sort of knowledge, and obtaining that knowledge has a bandwidth cost associated with it, no matter how smart you get about it. At the bottom of it, information theory is really thermodynamics, and you don’t get a free meal in terms of energy. Information is energy, so by obtaining it, there will always be expenditure. In any network, that expenditure is bandwidth (which is, again, energy). Let all nodes route traffic, and you end up wasting huge amounts of bandwidth on path/routing/maintenance traffic for potentially hundreds of nodes that will never actually route any traffic. And in addition, routing efficiency will be much worse, most packets will likely need many more hops than optimal. You design some algorithm that tries to elect optimal routing topologies. You are now wasting all your bandwidth on that. There’s a physical limit too, in terms of how many nodes your network can now support, which gets exponentially smaller when your medium speed drops. Goodbye to using LoRa and similar. You then say, to [heck] with it, and just decide [to flood route] everything, and hope for the best. Well, you see what happens here too. In the end, the approach Reticulum takes is the most optimal, and the only solution that is scalable and functional in the real world, even over very low-bandwidth mediums.

◀ Prev • Parts • Full • Next ▶